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ABSTRACT 


4 

This thesis presents a design and implementation of a 
drafting tool, "Object-Oriented Analysis Tool (OOATool ) " , for 
Object-Oriented Analysis. A user-friendly interface is 
designed to aid the user to analyze a system and build it's 
schema using 00A notation. The OOATool is implemented in 
C++, a block structured object-oriented language based on 
ANSI C language. 

The tool has a comprehensive set of operations to edit 
the 00A schema. It generates analysis document of the 
schema as required by the designer. Presently, it generates 
C++ class templates for the 00A schema. The main features of 
the OOATool are: 00A schema editing, scrolling in all four 
directions, browsing, consistency checking and precise error 


report 1 ng . 
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CHAPTER - 1 


INTRODUCTION 


1.1. Introduction 

The methods and tools used during software development 
can have a significant impact on the quality of final pro- 
duct. Over the past 15 years or so, the "Structured Tech- 
niques" have gained a great deal of acceptance as being the 
method that can assist the analyst and designer in the sys- 
tem analysis and design phases respectively. This method is 
based on a functional view of the system, with the system 
being partitioned according to its functional aspects. 

Recently a new approach to system analysis, Object- 
Oriented final Vs is( 000) , has been gaining popularity. 00A 

maps the problem domain directly into a model. Each object 
in the problem domain is mapped to an object in the model 
with similar behavior. The complexity of the problem domain 
is expressed as a set of classification structures and/or a 
set of assembly structures. Any similarity between a set of 
objects is captured in a classification structure. 00A also 
models the associations and interactions between objects. 

In the analysis process, the structure and functioning 
of system under consideration is understood and is formally 
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documented. The output of analysis process is a precise for- 
mal specification of the system which is passed as input to 
design phase. This thesis is an attempt to build an user- 
friendly analysis system supporting Object-Oriented 
Analysis. The design of the system conforms to the design 
principles of object-oriented development. More over, the 
impl ementat i on of the system is done in an object-oriented 
language to fully exploit the benefits of object-oriented 
design. 

1.2. Features of Object-Oriented Analysis Tool (OOATool > 

The following are the features of our OOATool: 

i> Schema Presentation: A concise and consistent 
notation is used to present the 00A schema. The 
concept of virtual drawing sheet enables the user 
to enter arbitrarily large schema. A set of edit- 
ing facilities allows the user to perform wide 
range of editing operations on the 00A schema. 

ii> Support for Incremental Analysis: The user can do 
his analysis incrementally, i.e., he can switch 
freely between different stages of anal ys i s ( i . e . , 
on layer by layer basis), without doing full depth 
analysis of one stage(layer) at a time. 

iii> Browsing: The user can browse the classes in the 
schema, attributes and services of a class. He can 
also see constraints on an instance connection or 



a whole-part structure of a c lass ( i nstance connec- 
tion and whole-part structure are discussed in 
chapter-2 ) . 

iv> Consistency: The system allows the user to enter 
only correct and consistent schema. Any operation 
leading to inconsistency does not pass through the 
system. The conflicts in naming of objects, its 
attributes and services, which cause schema to be 
inconsistent, are reported and the operation which 
caused the conflict is not done. Similarly the 
operation which cause the schema to be incorrect 
are denied by the system. 

1.3. Related Work 

In past few years, many tools for systems analysis have 
been introduced into the commercial market. These tools are 
supplied by vendors like Ed Yourdon(for Yourdon method), 
Michael Jackson(for Jackson method) and Oracle 
corporat ion(for OracleCASE) and others. The commercially 
available tools like Excelerator, TurboAnalyst and TurboCASE 
support Structured Analysis. 

Recently, the developers of Object Oriented 
Ana 1 ys i s (00A) , Peter Coad and Ed Yourdon are promoting 00A 
methodologyCCoad and Yourdon, 1991a], [Shlaer and Mel lor, 
1988]. Presently, some commercially available CASE tools 
supporting 00A are Object-Oriented Environment, OOATool and 
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Ob j ectPl us . 

Other tools might be in progress. 

1.4. System Architecture 

The architecture of OOATool is shown in Figure 1.1. The 
user interacts with the Interface Manager. The Modeling 
Manager communicates with Interface Manager to get input 
from the user. When the user requests for an operation on 
the schema. Modeling Manager sends a message to Schema 
Manager to effect the operation in the schema; and a message 
to Display Manager to display the operation that is done on 
the screen. 


Modeling Manager 



Figure 1.1. Architecture of OOATool. 
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1.5. Thesis Organization 

This thesis is organized as follows. Chapter-2 gives a 
brief introduction of analysis methods, object-oriented 
analysis terms and concepts. Chapter-? describes the user- 
interface of the system. Chapter-4 explains briefly 
object-oriented design methodology and the design of our 
OOATool . 

Chapter-5 presents the conclusions and further work 
that can be done to OOATool to make it a complete and usable 
tool. The Appendix contains C++ class implementations of 
different modules of the tool, user manual, and sample files 
generated by OOATool. 



CHAPTER - 2 


OBJECT-ORIENTED ANALYSIS 


2.1 Introduction 

Object-Oriented OnalVsisi 00A) is based upon concepts 
like objects and attributes, wholes and parts, classes and 
members. The approach of 00A builds upon three constantly 
employed methods of organization. They are: 

1> the differentiation of experience into particular 

objects and their attributes -- e.g., how do we distin- 
guish a tree by its size and/or its spatial relation to 
other objects. 

2) the distinction between whole objects and their com- 
ponent parts -- e.g., how do we contrast a tree with 

its component branches and leaves, and 

}> the formation of and the distinction between different 
classes of objects -- e.g., how do we distinguish 

class trees from class of all stones. 

Benefits of 00A are as follows: 

1. Explicitly Represent Commonality: 00A uses inheritance 
to identify and capitalize on commonality of Attributes 
and Services. 
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2. Build Specifications Resilient to Change: 00A embeds 
volatility within problem domain constructs, providing 
stability over changing requirements. 

3. Reuse Analysis Results: DOA organizes results based 
upon problem domain constructs for present and future 
reuse . 

4. Provide a Consistent Underlying Representat ion for 
AnalysisCwhat is to be built) and design (how it is to 
be built this tine): 00A establishes a continuum of 
representation for systematically expanding analysis 
results into a specific design. 

2.2 Analysis Methods 

DeMacro offers the following definition for systems 
analysis [DeMacro, 1978]: ’’Analysis is the study of a 
probl em( system) , prior to taking some action regarding the 

»t 

probl em< system) . In other words, analysis is the study of a 
problem domain, leading to a specification of externally 
observable behavior; a complete, consistent, and feasible 
statement of what is needed. 

This section surveys four major approaches to analysis. 
These approaches are thinking tools, used to help in the 
formulation of requirements. We illustrate each of these 
methodologies through an example problem later in this 
chapter(in Section 2.9). 



1) Functional Decomposition : This method has following 
three components: 

* Functions 

* Sub- f unctions 

* F unctional Interfaces. 

This method requires one to map probl em-doma i n < e . g . , 
student registration system) to functions and sub- 
f unct i ons[ Yourdon and Constantine, 1978]. The analysis 
documentat i on consists of required functions and sub- 
functions that the system shall provide. 

2) Data-flow Approach :This method is well-known as Struc- 
tured Analysis. The data-flow approach has following com- 
ponents : 

* Batafand Control ) flows 

* Data transformations 

* Data stores 

* Process Specifications 

* Data Dictionary. 

In this approach, the flow of data and the processes 
from/to which the data flows are identified and drawn. There 
are two major strategies are popular in structured analysis. 
The "old” methodCDeMacro , 1978], CGane and Sarson, 1977] 

maps the system to data-flow diagrams. The "modern” struc- 
tured analysis approachCMcMenami n and Palmer, 19823, CYour- 
don , 19893 first identifies the events that occur in the 
outside world. these events are then transformed to a pro- 
cess or a set of processes. Each process is names by decid- 
ing what the system must do in response to the event. 
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3) Information Modeling :The information modeling combines 
the concepts from Ent i ty-Re 1 at i onsh i p model and semantic 
data modelCChen, 1976], [Flavin, 1 981 ], [Hammer and McLeod, 
1981] and [Teorey et al . , 1986]. This approach has follow- 

ing components: 

* Objects 

* Attributes 

* Relationships 

* Supertv pe/Suhtvpes 

* Associative Objects 

This method has the following missing concepts: 
i> Services: describes the behavior of an object 

ii) Messages: a narrow, well-defined interface, dep- 
icting processing inter-dependency. 

iii) Inheritance: explicit representation of Attribute 
and Service commonality. 

iv) Structure: Whole-Part structures are not captured. 

4) Object-Oriented Approach :The Object-Oriented approach 
has the following components: 

* Class and Objects 

* Inheri tance 

* Communication with messages 

The 00A builds upon the best concepts from Information 
Modeling, Object-Oriented Programming Languages, and 
Knowledge-Base Systems. 
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Information Modeling 


Entitv- 

Rel ationshi p 

Diagrams 


Semantic 

Data 

Model ing 


* Attributes 

* Instance connections 

* Generalization and 
Special ization 

* Mhole-Part Structures 



Object-Orient, ed 
final Ysis 


Oh jec t-Oriented 
Programming 1 anguages and 
Knowl edge-Base SVstems 


Attributes and 
Exclusive Services 
Communication with 
messages 

Generalization and 
Special ization 
Inheri tance 


Figure 2.1 • Merging of disciplines 

A comparative study of object-oriented and structured 
developments can be found in CPatrick, 1990]. 

2.3. Object-Oriented Analysis Approach 

In an overall approach, 00A consists of five major activi- 
ties. They are: 

i> Finding Class&Ob j ects 


ii> Identifying Structures 

iii) Identifying Subjects 

iv) Defining Attributes 


v > 


Defining Services 
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The OOA model is presented and reviewed in five layers: 

Subject- LaVer 

Cl ass&ObJect LaVer 

Structure LaVer 

attribute LaVer 

Service LaVer 

Figure 2.2‘ The mult-i-laVer model 

2.3.1. Class&Ob ject Layer : 

In this layer the Classes- and Class&Ob j ects that exist 
in the problem-domain are identified. 

DEFINITIONS: 

Class : 


Class is a 'description' of one or more Objects with a 
uniform set of Attributes and Services. 

Object : 

Object is an 'abstraction' of something in problem 
domain, with independent existence. 

Class&Ob j ect : 

Class&Object refers to a Class which creates Objects 
existing in the problem-domain. 

e.g.: In an Sensor System, one can identify two 

Class&Ob j ects Sensor and Critical Sensor and no Classes. 


11 
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Notation . 


Cl ass 


Figure 2.3a • The OOF) "Class" sVmbol 



— 


- 


Sensor 






Figure 2.3b J The 000 "Cl ass&Object" sVmbol 


2.3.2. Structure Layer : 

In this layer the Genera I i zat ion-Spec i al i zat i on (Gen- 
Spec) and Whole-Part structures that exist in the system are 
i dent i f i ed . 

DEFINITIONS: 

Structure: 

Structure is an expression of problem-domain complex- 
i ty . 

General i zat i on -Spec i a 1 i zat i on Structure: 

Genera 1 i zat i on-Spec ial i zat i on(Gen-Spec > structure is a 
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hierarchical organization of a set of classes in the 

problem-domain. A Generalization-Specialization struc- 
ture forms either a hierarchy or a lattice. 


e a • In an organization, the following two Gen-Spec struc 
tures can be identified. In the following figure Person, 
OwnerPerson and Empl oyerPerson form a Gen-Spec Hierarchy 
Structure and OwnerPerson, Empl oyerPerson and OwnerEmploy 
erPerson form a Gen-Spec Lattice Structure. 


Notation J 



Whole-Part Structure: 

Whole-Part structure is an organization of classes 
showing container class and the contained classes. 


e.g.: While analyzing a vehicle class 
Part structure can be identified. In 
is container class and Engine, Frame 


, the following Whole- 
this structure. Vehicle 
and Wheel are contained 


classes . 





Figure 2.5 J The Hhole-Part- structure notation 


In the above example an engine is a part of: 

* possibly no vehicle 

* at most one vehicle 

and a vehicle is an assembly of: 

* one engine 

* one frame 

* three or four wheels 
2.5.3. Subject Layer : 

This layer gives an overview of a large 00A model 
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DEFINITIONS : 

Sub j ect : 

A Subject is a mechanism for guiding a reader through a 
large and complex model. 

Importance of Subjects? 

In order to ease the comprehension of the problem- 
domain, two or more classes are to be grouped to form a 
higher level abstracted entity called Subject. Subjects 
are identified to control the amount of complexity con- 
fronted by the reader. Thus subject layer presents 
overall model from an higher perspective. 

Natation'- 

1. Subjectl 


2. Subjects 


Figure 2.6a- Subject notation r collapsed 


< 


1. Subject 1 


2. Subject-2 

1. Class&ObjectI 


1. Class&ObjectS 

2. Cl ass&0bject2 


2. Class4 



% m * * 

' ' ' • 


* » • % 


Figure 2 -6b'- Subject Notation , partial 1 V 
expanded ( a CPSE tool option) 
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2.3.4. Attribute Layer : 

DEFINITIONS: 

Attr i bute : 

Attribute is some data(state information) for which 
each Object in a Class has its own value. 

Importance of Attributes: 

Attributes add detail to the Class&Object and Structure 
abstractions. Choosing Attributes involves analysis and 
one's personal choice. Attributes are placed in the 
center section of the Class&Object and Class symbols. 

e.g.: For a Sensor Class&Ob j ect , some of its attributes can 
be identified as Model, Location, Threshold, State, Value. 

Notation ■ 

Sensor 

Model 

Location 

Threshol d 

State 

(Jal ue 


Figure 2.7 - Placing attributes in a Class&Object 

Attributes describe va 1 ues ( state ) kept within an 
Object, to be exclusively manipulated by the Services of 
that Object(we will describe Services of Object shortly in 
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Service Layer). If another part of the system needs to 
access or otherwise manipulate the values in an object, it 
must do so by specifying a Message Connect i on ( th i s also we 
will describe in Service Layer) corresponding to a Service 
defined for that Object. 

Instance Connection: 

Instance connection model an association between two 
ob j ects . 

If an Object needs association with another Object, 
this is represented by an Instance Connection between them. 
It is shown with a line drawn between the Objects. The 
Instance Connection is between two Ob j ects ( rather than 
between Classes). Each Object has amount(m) or range(m.n) 
markings on each of its Instance Connections, reflecting its 
constraints with other Objects. 

e.g.: In an Institute system, the association between a stu- 
dent and a faculty member can be identified as: 

Notation i 


Student 

1,2 guided bv 0,4 

' 

. Facul t V 
' Member 


'■* guides 





Figure 2. Si Instance connection notation 

In the above figure, a student can be guided by one or two 
faculty members and each faculty member can guide zero or 
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four students. 

Instance Connection can be labeled for better under- 
standing, if the labels would not cause cluttering. Usually 
the label is avoided if the meaning of the association is 
clear from the context. 

2.3.5. Service Layer : 

DEFINITIONS: 

Service: 

Service is a specific behavior that an object exhibits 
when looked from outside the object. 

Importance of Services: 

Services further detail the abstraction of the reality 
being modeled, indicating what behavior will be pro- 
vided by an Object within a Class. They also provide 
communication between Objects. Services are placed in 
the bottom section of the Class&Object and Class sym- 
bols. 

e.g.: For a Sensor Class&Object, some of its attributes can 
be identified as Model, Location, Threshold, State, Value. 
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Notation: 



Figure 2.9: Placing services in a Class&Qbject- 
Message Connection: 

Message Connection models the processing dependency of 
an Object, indicating a need for Service(s) in order to 
fulfill its responsibilities. 

A Message Connection is a mapping of one Object to 
another Object, in which the "sender" sends a message to the 
"receiver" to get some processing done. The needed process- 
ing is named in the sender’s services specification, and is 
defined in the receiver’s service specification. 


Notation: 


Sender 


Recei ver 


= h 






Figure 2.10a: Message connection to single object 
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=> 


zj To manV objects 

=> 


Figure 2.10h’- Message connection to nanV objects 


Sender 


L 


2.4. More about Each Layer: 

In this chapter, we briefly described OOA concepts, 
terms, and notation. For detailed ob j ect-or i ented analysis 
methodology of each layer, we request the reader to refer to 
CCoad & Yourdon, 91 ] . 



2.5. A CASE STUDY 
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EXAMPLE : Students Registration System 

This problem is analyzed using the four major 
approaches to analysis. 

Probl em- Domain Description '■ 

In an Institute , students are enrolled every semester, 
fill the students should register for a minimum number of 
credits. Every student will be guided bV a faculty 
member ( instructor) . fi faculty member can guide at most four 
students . fin instructor can offer at most three courses . fi 
student is allowed to register only if‘- 

1) . he cleared all dues to the institute, library and 

hostel , 

2) . he secured the required minimum CPI in the last 

semester. 

fi student is allowed to drop a course and add a new 
course with the consent of the concerned instructors . 
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Functional Decomposition : When the students registration 
system is viewed from functional view point, two main func- 
tions Reg i ster_new_student (. > and Regi ster_old_student ( > are 
identified. The function Reg i ster_new_student O is decom- 
posed into sub- f unc t i ons Va 1 i date_new_student < ) , 

check_f or_dues < ) and Add_course ( ) . The Add_course() 

sub_function is further decomposed as shown in the following 
figure. The decomposition of the sub-function Drop_course() 
produces a new sub-function Drop_course_f or_student ( ) , in 
addition to having Val idate_course_no() and 

Va 1 i dat e_ i ns true tor ( ) . Two additional sub-functions 
Va 1 i date_o 1 d_student ( > and check_f or_requ i red_CPI ( ) are 

identified when the function Regi ster__old_student ( > is 
decomposed. The functions and sub-functions that are iden- 
tified are shown as a tree in the figure 2.1. 


Reg i ster_new_student ( ) 

Val idate_new_student( ) 

Check_f or _du.es < ) 

Add _course( ) 

Val idate_course( ) 

Val idat-e_course_ti tle( ) 

Val idate_instructor( ) 

Val i date_cred i ts( .> 

I Add course for studentf ) 


■ Dr,op_course< ) 


-Drop_course_for_studer>t( ) 


Reg i ster_ol d_student( ) 


Val idate_ol d_student( ) 

' Chec k_for_reQui red_CPI ( ) 



M 


F igure 


11’ The Functional Decomposition for Student 
Registration SVstem 



ta flow Approach : 

gistration system 
gure 2.2. The DFD h 
ons and sub-funct 
composition. The ma 
1 e , Dues file, Reg 
udent courses file. 



udents 
i(DFD> in 
e func- 
nct i ona 1 
Students 
file and 
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The data dictionary showing the structure and exact 
contents of each of the data-flow for students registration 
system is shown below. 


Student-s_f i 1 e - f Rolljpo + Student _n am e **■ Programme + Department- 

PddressC Hall_no + Room_no J J 

Reg i stered_student-s_f He - C Rolljno + Academic _V ear + semester + 

Reg i strati on_date J 

Courses_f He - € Course_no -f- Course_t-i tl e + Units + Instructor _name 

Instructors _initial s J 

Course - f Course_no + Units J 

St-udent-s_courses_f i 1 e - C Roll_no + C Course_no + Registration _tvpe 
' + Thesis_supervisor J 

Registrat-ianjbvpe - /few / Repeat / Substitute 

Dues file - £ Roll no + Due to whom + £ Due amount / £ Books J* J* J 


Figure 2.13i The Data Dictionary for Student Registration System 
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Information Modeling : The analysis of students registra- 
tion system through information modeling approach uncovers 
two new entities Person and Instructor. The model captures 
additional semantics of the real-world through IS_A hierar- 
chy. The semantics of "an instructor guiding a student" and 
"an instructor offering a course" are also represented 
through relationships "guides" and "offers" respectively, 
the complete Entity-Relationship diagram is shown in the 
f i gure 2.4. 



Figure 2.14 • The EntitV-relationsbip diagram 
for student registration s Vs tern 
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Object-Oriented Approach : The ob j ect-or i ented analysis 
approach identifies the complete behavior of all objects in 
the system through services explicitly. For example, the 
behavior of Regi stered_student is captured in the services 
Take courses. Pay dues and drop course. The constraints on 
the association between (Student, Instructor) and (Instruc- 
tor, Course) are explicitly specified. The communication 
between objects is also shown as double line arrows. 



Figure 2.15 s The Students Registration System - 
Cl ass&Object , Structure , Attribute 
and Service 1 avers 
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SUBJECT LAYER 




Dues 


fig are 2.16a’. 


The subjects 


in Students Registration 


System 


1. Person 


2. Hues 


3. Coursem 

1. Student 
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figure 2.16h- 


The partially expanded subjects in Students 
Registration System 

























SERVICE LAYER 



Figure 2.20 ' The Service lever in the Students 
Registration S vs tea 










CHAPTER - 3 


OOATool - USER INTERFACE 


3.1. Introduction 

A good user interface plays an important role in a 
software system. In future, the fast increasing raw comput- 
ing power of processors will be consumed mostly in executing 
the user interface portion of the executable code. Designing 
an user interface keeping in mind both experienced user and 
naive user is a tough job. 

In OOATool, all the interactions of the user is done 
through windows. The user interface contains seven types of 
windows. They are: 

i ) . Menu Wi ndow 

ii>. Drawing Sheet Window 

i i i ) .Help Window 

iv>. Report Window 

v ) . Error Wi ndow 

vi>. Dialog Window 


v i i ) . I nf o Window 



The screen layout of OOATool looks like: 



Figure Z.l- The screen laVout of OOATool 


We will describe each window briefly in next section. 


5.2. User Interface Description 


i) Menu Window : 


Initially the root menu will be displayed in this win- 
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dow. All the commands in the root menu are ALT key followed 
by a character. e.g., ALT-0, ALT-C. When you press any key 
in the root menu, a sub-menu is displayed: The sub-menu 
items can be selected by just pressing corresponding item's 
character. In the last sub menu, when you press a key in the 
sub-menu, a dialog/info window is displayed at the center of 
the screen. The root menu and a sample sub-menu is shown 
below: 



Figure 3.2i The root menu and a sample sub- menu 

ii> Drawing Sheet Window : 

This window shows a portion of virtual drawing sheet on 
which the user draws the 00A schema. The title bar, the 
top-most horizontal bar of the window, contains the 
currently opened schema file name. At the bottom left hor- 
izontal bar of the window the current cursor position is 
displayed as xxx:yyy. 

Using arrow keys cursor can be moved in all four direc- 
tions up, down, left and right. When the cursor is at the 
edge, moving the cursor causes the drawing sheet window 











scroll in that direction. This enables to view the whole 
drawing sheet. 

i i i > Help Window ; 

A help message is displayed in this window, which helps 
the user through a sequence of operations. When a help mes- 
sage is displayed the system waits for some key being 
pressed, to ensure that the user read the message. Since the 
system guides the user through proper sequence of opera- 
tions, he is freed from learning of some complicated 
sequence of schema editing operations. 

iv> Report Window : 

The report window overlaps with Help Window. Whenever 
an operation is performed on the schema, the outcome of the 
operation is reported in this window. Any system related 
messages are also displayed in this window. 

e.g.: A sample report message looks like: 

Report: Schema opened successfully 

v) Error Window : 

In the error window, errors occurred while performing 
an operation on schema or on drawing sheet are displayed in 
red color. Whenever an error is displayed, the system waits 
for a key press in Help Window saying: 
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"Did you acknowledge error message?[press any key]" 

The system ensures that user has read the error message by 
waiting for a key press by the user. 

e.g.: A sample error message looks like: 

Error: The class with name: xxx not found in the schema 

vi) Dialog Window : 

Dialog window is designed to take input from the user 
before doing an operation on the schema. For example, the 
ALT-OIA command brings the following dialog window on the 
screen: 



Figure 3.3i f) sample dialog window of OQATool 

Now the system expects the user to enter a class 
name < i . e . , a string) and the type of the class(i.e., either 
Cls stands for class or ClsObj stands for Class&Ob ject) . 
After entering the input, select OK box and press RETURN key 
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there. The dialog window disappears and the corresponding 
operat i on ( i . e . , adding a class to the schema) is performed 
and the message will be displayed in Report/Error window. 

vi i > Info Window : 

When the user wants the system to display some informa- 
tion, it is displayed in Info Window. For example, the ALT- 
OIB command brings an Info window on the screen as: 

I Browsing the classes in the schema — - ■ ■■ 

1. ClassNamel 
2- Cl asj>Name2 
3. Cl assNameS 


Figure 3,4- A sample info window of OOATool 

The user can scroll up and down, if he wishes, in Info 
window. When RETURN key is pressed, a message is displayed 
in Help Window saying: 

"Have you finished browsing through the classes?” 

and waits for a key. Pressing any key will cause the Info 
window to disappear from the screen. Currently, OOATool 
allows user to browse: 


a) 


attributes of a class 
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b) services of a class 

c) instance connection of a 

d) whole-part connection of 


class and 

a class 



CHAPTER - 4 


DESIGN AND IMPLEMENTATION 
4.1 Object-Oriented Design - An Introduction 

The design of OOATool is influenced much by the Object- 
Oriented Design Methodology. For the sake of completeness, 
we briefly discuss Object-Oriented Design Methodology here. 

In traditional Structured Deve 1 opment ( i . e . , the three 
processes of structured analysis, structured design, and 
structured programming), which takes functional viewpoint, 
functions and procedures form primary where as data is 
treated as secondary. But in Object-Oriented paradigm data 
is considered primary and procedures are secondary. The 
procedures ( i . e . , methods in Object-Oriented terms) are tied 
to the data. 

The central problem during the Object-Oriented design 
process is identifying the objects and the operations 
defined on the objects. there are three phases in this 
approach : 

i) producing the initial design 

ii> function refinement 

iii) object refinement 

The idea is to start with initial high-level design of 
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the system, with high-level objects and the functions 
described in terms of sub-functions. In later phases the 
objects and sub-functions are treated as systems and the 
whole process is repeated for them, until we reach a stage 
where the objects are "atomic objects" that can be imple- 
mented directly, and all the functions are completely 
def i ned . 

i) Producing the initial design : 

In this phase the objects and their operations are 
identified. This is done in three steps. 

a) develop a strategy to solve the problem, 

b) extract the objects and the operations on these 
objects from the strategy statement, 

c) establish the interface of each of the identified 
objects. 

i i ) Functional refinement : 

This is an iterative process, with the input 
refinement coming from the initial design. As the func- 
tional refinement proceeds, new objects and operations 
on them are identified. In addition, during a refine- 
ment step, operation may also be identified on objects 
that were identified in earlier refinement steps. 

When the functional refinement process terminates. 
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all the objects in the .problem space are identified. 
However, more objects (and their functions) may be 
uncovered when object refinement takes place in the 
next phase. But those objects would be nested within 
the objects identified by the end of this phase. 

iii) Object refinement : 

The aim of this phase is to identify the new 
objects and their operations that are required in order 
to implement the objects. For a large system the 
objects may be very high-level, with complex operations 
that may encompass many objects. 

The new objects that are identified during refine- 
ment of an object are an outcome of the attempt to 
specify the operations of the object undergoing refine- 
ment. Hence the purpose of these new objects is to pro- 
vide services that are utilized to implement the opera- 
tions of the original object undergoing refinement. 
These new objects should naturally be regarded as 
nested within the object whose refinement uncovered 
their existence. In such situations the nested objects 
are not(and need not be) visible outside the parent 
object. 

Once all the operations on the parent object are 
identified, refinement of nested objects can begin. The 
refinement process terminates when the objects are sim- 
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pie enough to be implemented directly. Only for 
extremely large and complex systems, the nesting of 
objects is expected to be very deep. 

For more details on the methodology the reader is 
requested to refer to CJalote, 1991]. 

4.2. OOATool - Design and Implementation 

The OOATool is implemented in C++, a block structured 
Object-Oriented language based on C language. The tool con- 
sists of following five modules: 

i> Modeling Manager Module 

ii) Display Manager Module 

iii) Schema Manager Module 

iv) Drawing Sheet Module 

v) Interface Manager Module 
i) Modeling Manager Module: 

The Modeling Manager is composed of a Display Manager 
and a Schema Manager. As extensions to OOATool, if we add 
Print Manager, Help Manager etc., all of them go will into 
Modeling Manager at the same level as Display Manager and 
Schema Manager. Modeling Manager interacts with Interface 
Manager to get input from the outside world and sends 
appropriate messages to Display Manager and/or Schema 
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appropriate messages to Display Manager and/or Schema 
Manager as required. In OOATool, the complete behavior of 
Modeling Manager is coded in the method Modeling 
Manager :: Dr i ver( ) . The C++ class implementation of Modeling 
Manager is listed in header file modelm.h, given in the 
Append i x . 


Modeling Manager 



Figure 4.1- Modeling Manager Organization 

ii> Display Manager Module: 

The Display Manager inherits properties of Window 
class(the implementation of Window class is listed in the 
header file window. h, given in the Appendix. The Display 
Manager displays the 00A schema (i.e., drawing sheet con- 
tents) on the screen. It creates the Drawing Sheet window 
when a schema is loaded and performs the editing operations 
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on the drawing sheet when requested. 



Figure 4.2 • l Display Manager Organization 


The Display Manager contains with a drawing sheet, 
whose dimensions are unlimited(of course, limited by the 
maximum file size of the operating system). The Display 
Manager displays only a portion of the drawing sheet in the 
drawing sheet window. The user sees the drawing sheet 
through a 18(rows) X 78<columns) size view port. The C++ 
class implementation of Display Manager is listed in the 
header file dspm.h, given in Appendix. 

iii> Schema Manager Module: 

Schema Manager is responsible for managing all the 
classes currently entered in the schema. It maintains 
pointers to the classes in an array. Though the classes can 
be maintained as a linked list, array is preferred due to 
the following reasons: 
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a> To avoid designing of an extra C + + class, 

ClassNOb j ectL i st , which is spurious and does not 
fit naturally in the problem space, 

b) To simplify the design and at the same time 
improve the readability of the design, 

c> To simplify the iteration operation over the list 
of classes and thus improving the performance sig- 
n i f i cant 1 y . 

The information about classes in the schema is 
loadedCstored) from(to) a file "f i 1 ename . str" when a schema 
is openecHclosed) . The C++ class implementation of Schema 
Manager is listed in the header file schm.h, given in Appen- 
dix. 



iv> Drawing Sheet Module: 

This module implements a virtual two-dimensional draw- 
ing sheet through a UNIX FILE stream. It provides facilities 
to write a string horizontally or vertically on the drawing 
sheet and to read a chunk of byte from FILE stream. The C++ 
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class implementation of Drawing Sheet is listed in the 
header file drgsh.h, given in Appendix. 


Brakji nQ Sheet- 


1 


FILE stream 



— L 


Figure 4.4 i Drawing Sheet Organization. 

v> Interface Manager Module: 

This module is a set of classes; each class is a sub- 
class of Window class. When an instance of one of these 
classes is created, its interface window is displayed on the 
screen. It either takes input from the user or displays 
schema related information in the displayed window. The 
window disappears from the screen as soon as the instance is 
destroyed. These classes are utilized by the Modeling 
Manager module when it wants to interact with the user. The 
C++ class implementation of Interface Manager is listed in 
the header files intfwin.h, intfwins.h and infowin.h in 
Append i x . 

Finally, we describe a simple and uniform communication 
protocol that is followed among the various modules of 00A- 
Tool. The modules communicate with each other through a 
message, which has been implemented as C++ Message class. 
Whenever a sender(a method) sends a message to recei ver(a 
method in the same class or in another class) the receiver 
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replies the outcome of message execution by creating an 
instance of Message and returning it to the sender. The 
sender after receiving the Message from receiver does the 
required clean-up operations based on the outcome. The C++ 
class implementation of Message is listed in the header file 
message. h given in Appendix. 



CHAPTER - 5 


CONCLUSIONS AND FURTHER WORK 

If the system under consideration is large, the number 
of objects identified will also be large. Then it becomes 
difficult for the analyst to remember/reco 1 1 ect the names of 
the all classes, its attributes, its services and other 
information. The analysis document for such large system 
tend to become so huge that ensuring consistency and 
correctness when a slight modification is done to a portion 
of the schema will be a tedious and painstaking job. Under 
such c i rcumstances , using a tool like OOATool will defin- 
itely increase the productivity of the analyst. 

Even though OOATool provides editing and document gen- 
eration facilities, present implementation does not meet 
many demanding features for a professional analyst. We fore- 
see the following extensions to OOATool. 

i) facility to categorize attributes and services as 
private. protected and public, which enables con- 
trolling the access to them by sub-class and other 
classes(in the spirit of C++), 

ii> support for specifying the all services that are 
needed by a service of a class, 

iii) adding support for subject layer, which is 
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presently missing in this implementation, 

iv) on-line help facility giving directions how to go 
about analyzing further at any stage, 

v) provisions for editing multiple 00A schema simul- 
taneous 1 y , 

vi> presently the number of classes that can be 
entered in the schema are limited by the operating 
system 1 i mi tat i ons ( 1 i ke in DOS on personal comput- 
ers, maximum memory is 640KB). This is because 
present implementation stores all schema related 
data in main memory. To support large number of 
classes OOATool can be linked to a Database 
Management System to store schema related informa- 
tion. 
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Append ix-A 


User's Manual 

Hardware and Software requirements: 

OOATool runs on the IBM PC family of computers. It 
requires DOS 2.0 or higher and with at least 640KB. It runs 
on any 80-column monitor. The minimum requirement is a hard 
disk drive and one floppy drive. OOATool is to be run from 

hard disk drive for faster response time. OOATool accesses 

the schema file "xxx.sch" most frequently since whenever the 
drawing sheet is scrolled in the drawing sheet window, the 
contents are read from the file "xxx.sch". OOATool is 
implemented in Turbo C++ version 1 . OOCBorland , 1990a], [Bor- 
land, 1 990b] , [Bor land , 1990c]. To start OOATool type: 

C : > ooatool <CR> 

The tool first displays a welcome message and opens a 
default schema with file name "ooa.sch". 

Loading and Closing a schema: 

If you want to load a schema other than the default 

"ooa.sch", press <F?> key. Now the system closes the current 

schema and asks for a new schema file name. The file name 
"xxx" , should be entered without the extension ”.sch". The 
system will open the schema file as "xxx.sch". The current 
schema can be closed by <ALT-F3> key. 
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Menu Reference: 

The following command keys are available in DOATool . 

ALT-0 : for doing operations related to Class. 

ALT-C : for doing operations related to Connect ion<Gen- 
Spec/Whole- Part structure or Instance/Message con- 
nect i ons > 

ALT-A : for doing operations related to attribute of a Class 
ALT-S : for doing operations related to service of a class 
ALT-D : for drawing sheet related operations 
ALT-X : exiting from OOATool. 

ALT-0 menu: 

A: adding 

This command can be selected by pressing ’a’ or ’A' 
character. The command displays a dialog window 
expecting "Class Name" and "Class Type" from the 
user. You can move over the input boxes by up and 
down keys or TAB key. After entering the input, 
select OK box and press return. 

D: deleting 

This command deletes the names class from the 
schema . 

B: browsing 

You can choose this command when you want to see all 
the Classes that are there in the schema. 

P: repaint 


This command is 


chosen 


when 


you want 


to 
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repa i r ( repa i nt > an Class or its connection. Choosing 
this command redraws the Class and all its connec- 
tions and thus repairing any damage. 

R: relocate:- 

You choose this command when you want to make space 
on the drawing sheet by re 1 ocat i on (mov i ng) the 
object to different location on the drawing sheet. 
ALT-C menu: 

G : Gen-Spec : - 

This command displays a sub-menu consisting of Gen- 
Spec connections types.- H: hierarchy connection 
L: lattice connection 

Choosing any one option will display another sub- 
menu with the following two options: 

A: adding 

adds the specified Gen-Spec connection. 

D : deleting 

deletes the selected Gen-Spec connection. 

W: Whole-Part :- 

This command displays a sub-menu with items 
A: adding •- 

adds the specified Whole-Part connection. 

D : deleting : - 

deletes the selected Whole-Part connection. 

B: Browsing :- 

displays the complete whole-part connection 


in an info window. 



I : I nstance : - 
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This command displays a sub-menu identical to the 
sub-menu of Whole-part Menu. 

M: Message :- 

This command displays a sub-menu with the items 
A: Adding :- 

adds a specified message connection 
D : Deleting 

deletes a selected message connection 

ALT-A menu: 

ALT-S menu: These two commands display a sub-menu with items 
A: adding 

adds an attribute/service to an object. 

D : deleting : - 

deletes an attribute/service from an object. 
B: browsing : - 

displays all the attributes/services of an 
object in an info window. 

ALT-D menu: 

E: use eraser :- 

makes the cursor as eraser. This is useful 
when some stray characters on the drawing 
sheet are to be erased. 

X: expand :- 

expand the size of the drawing sheet to 
specified dimensions. 


T: generate templates :- 
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generates C++ templates in a file xxx.tmp. 

D: generate document 

generates an analysis document for the 
schema in a file xxx.doc. 

<F2> Key : Stores the schema to a file xxx.str. 

<F8> Key : displays the available main memory. This gives 

you an idea how safe it is to do an operation 
without running out of main memory. This prevents 
the systems from hanging up if it runs out of 
memory . 

<Home> Key, <End> Key : These keys are context sensitive. 

The function of the key in a context is reported in 
the help window. 

<Up Arrow>, <Down Arrow), <Left Arrow) and <Right arrow) 
Keys : These keys move the cursor on the drawing 
sheet window. 

<Sh i f t-Home > , <Shift-End>, <Sh i f t-PgUp> , <Shift-PgDn> Keys : 

These keys move the drawing sheet left, right, up 
and down by the full dimension of the drawing sheet 
wi ndow< i . e . , shifts by 70 columns horizontally or 
shifts by 8 rows vertically). 

<Ctr 1 -Home> , <Ctrl-End>, <Ctrl-PgUp>, <Ctrl-PgDn> Keys: 

These keys move the drawing sheet left, right, up 
and down by half the dimension of the drawing sheet 
wi ndow< i . e . , shifts by 35 columns horizontally or 
shifts by 7 rows vertically). 
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OOA Notation in OOATool : 


The exact notation of OOA is not followed due to imple- 
mentation problems <the problem is OOATOOL uses the screen 
in Text mode and one cannot display graphic notation in text 
mode). An alternate notation is followed. Class and 


Class&Ob j ect : 



Class 


Class & object 






Figure A.l: The OOATool "Class” and "Class&Ob j ect" 
symbo 1 s 

Gen-Spec Hierarchy Connect i on< Structure ) : 



Figure A. 2a: The OOATool "Gen-Spec Hierarchy" 
Structure notation 









Figure A. 4: The OOATool "Message" Connection notation 






A message connection can be of the following four types 

Notation 

1. Object to Object | 

2. Object to Class j 

3. Class to Object | 

4. Class to Class | 

In OOATOOL a class is always displayed as: 

Class Name 

ATTRIBUTE 

SERVICE 


Figure A. 5: Display of a class in OOATool 


The attribute and services of a class are not displayed on 
their corresponding horizontal sections. This is due to 
following two reasons: 

1. User will not be interested in looking at the 
attributes and services always. 

2. To minimize the screen space occupied by a 
class symbol on the drawing sheet window, so that 
more classes can be displayed on the screen at any 


time. 
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The following files are generated by OOATool . Let the 
ame of the schema opened be "xxx". 

File Name Description 

xxx. sch This file contains the drawing sheet. 

The schema diagram that is shown in the 
drawing sheet window is stored in this 
file. 


xxx . str 


This file stores all information about 
the classes in the schema. 


xxx . i nf 


This file stores extra information about 
the attributes and services of a class. 


xxx . tmp 


xxx . doc 


The C++ class templates for the classes 
in the schema are stored in this file. 

The analysis document that is generated 
for the schema is stored in this file. 



AddWholePartConnectl void ) r 
AddlnstanceConnectt void ), 
AddMessageConnect ( void ); 
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void DelGenSpecHyConnecti void ), 

DelGenSpecLatConnect ( void ), 
DelWholePartConnectt void ), 

Del Inst anceConnectf void ), 

DelMessageConnectt void )j 

void DisplayClassest void ), 

DisplayWholePartConnectt void ), 
DisplaylnstanceConnect ( void ), 
DisplayAttributesl void ), 

DisplayServicest void }; 

void Driver i void ), 

RedrawObjectAndConnectsi char * ), 

ResetCursort void ); 

Message *RelocatettijectAndConnects( char * r Location # ); 

h 


inline ModelingManager::ModelingManager( char *fnaae ) 
{ 


OpenScheinat fnante ); 

5 

inline Model ingManager: : "Model ingManager 0 

{ 

CloseSche«a(); 

1 

inline void Model ingManager ::GetDrgShtLod Location #loc ) 
{ 

DspMgr->6etLoc( loc 1; 

1 

inline KEY Model ingManager : iRoamOnScreent ) 

{ 

return DspMgr->Roa»OnScreen(); 

1 

inline void ModelingManager::ResetCursor( void ) 

{ 

DspHgr ->ResetCursor 0 ; 

1 


fend if 
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/#m*#####*#*#**#**#* Class implementation of a##**##*##**#****#* 
###*»*#*#***#S3M****** Display Manager ******************#/ 


iifndef _DSPM H 
idefine _DSPM_H 

♦include "drgsh.h" 

♦include "window.h" 

♦include "message. h" 

const SCREENWIDTH = 80, //no of columns in the CRT screen Text mode 

SCREENHEIGHT = 25; //no of rows in the CRT screen in Text mode 

const MAX DISP ATTR = 1, 

MAXJDISPJ5ERV = 1? 

const BOXLEN = 17, 

BOXWID = 5+MAX_DISP_ATTR+MAX_DISP_SERV; 

const FULLSCREEN = SCREENHEIGHT -4; 

class DisplayManager : private Window t 
private: 

DrawingSheet *DrgSht; 

unsigned DLength, 

DHeight; 

unsigned #DspLnPtrs; /* file offsets in the drawing sheet 

of the lines that are currently 
displayed in the drawing sheet window 

#/ 

char *DspBuf; /# display buffer for the drawing sheet 

window */ 

void BufLeftScrollt unsigned ), 

BufRightScrollt unsigned ), 

BufUpScrolK unsigned ), 

BufDnScrollt unsigned ); 

void MoveCurLeftt unsigned ), 

MoveCurRightt unsigned ), 

NoveCurUpt unsigned ), 

HovecurDownt unsigned ); 

Message #6etLinePointst Location #* )? 

void DrawLinet Location #, Location #, char, char ), 

DrawPolyLinet Location ##, char, char, char, char ), 

PutChart char, Location * ); 



public: 
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DisplayManagert char #fname ="ooa.5ch", 
int left =1, int top =2, 
int right =SCREENWIDTH, 
int btm =SCREENHEIGHT-4, 
int fgc =YELL0W, int bgc =BLIE); 

"DisplayHanagerO; 

void Outline ( void ); 

void ResetCursori void ) { ResetCurO; } 

void Sho«( void ), 

OpenDrgShitchar #), 

ExpandDrgSbt ( int, int ), 

DrawObjectt char #, ClassType, Location * ), 
a aseObjectt Location * ), 

UseErasert void ); 

void DrawMessageConnect ( Location #, Location *, Location #*, 

ConnectionCategory ), 

DrawInstanceConnectf Location *, Location #, Location #s ), 
DrawWholePartConnecti Location *, Location #, Location ** ), 

DrawSenSpecHyConnecti Location #, Location *, Location ## ), 
DrawSenSpecLatConnectt Location *, Location *, Location m ); 

Message *MoveVerticalConnect( Location *, Location *, Location #, 

Location #, Location *, Location * ), 
#HoveHorizontalCannect( Location #, Location #, Location #, 
Location *, Location * r Location * ), 

#ShiftGenSpecHy Connect ( Location *, Location #, Location m ), 
«ShiftSenSpecLatConnect( Location s, Location *, Location #* ), 
#ShiftWholePartConnect( Location *, Location #, Location ** ), 

*ShiftInstanceConnect( Location *, Location #, Location ** ), 
sShiftMessageConned ( Location *, Location *, Location ** 1; 

void RedrauGenSpecHyConnect ( Location ** ), 

Redrav6enSpecLatConnect( Location ** ), 

RedrawWiolePartConnectt Location *s ), 

RedrawInstanceConnect ( Location ** ), 

RedravMessageConnectC Location #*, ConnectionCategory If 



void ErasePolyLinet Location ** ); 

void GetLocf Location * ); 

int RoamOnScreent void ); 

void LeftHovet unsigned ), 

RightMovet unsigned ), 

UpMovet unsigned ), 

DovnMove < unsigned ); 

int RetDrgSitLengthO { return DrgSht->Length(); } 

int RetDrgShtWidthO { return DrgSht->WidthO; 5 


#endif 
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/a###*##**##**#*****##*** Class implementation of a***************** 
##**#****#***»»*»*»»*»»** Schema Manager ^»#^##**####****/ 

iifndef _SCHM_H 
♦define _SCHM~H 

♦include "clsnobj.h" 

♦include “common. h" 

♦include "message. h" 

♦include "ooa.h" 

♦include <stdio.h> 

const MAXJ3BJECTS = 50; 


class Schemattanager { 
private: 

unsigned ObjCount; 

ClassNObjed sSchListl HAXJ3BJECTS 3; 

char #Fname; 

FILE sSchStore; 

ClassNObjed *RetObjPtr( char * ), 

*RetObjPtr( Objectld ); 

void Del6enSoecHyConnect( GenSpecConnection * ). 

DelGenSpecLatConnect ( GenSpecConnection * ), 
DelWholePartConnectt HholePartConnection # ), 
Del Inst anceConnectf InstanceConnedion * ), 
DelMessageConnectt MessageConned ion * ); 

public: 

Schemaltanager ( char * ="ooa.str" ); 

"Schemaltanager 0; 

friend class ModelingManager; 

void LoadScbemat void ) r 
StoreSchemat void ), 

LoadDocumentlnfot void ), 

StoreDocumentlnfot void ), 

SenerateTeaplatest void ) r 
GenerateDocusentt void ); 

Message *AddClsN0bj( char *, ClassType, Location * ) r 
*DelClsN0bj< char * ); 

Message *AddGenSpecHyConnect( char #, char * ), 
#DelGenSpecHyConnect( char *, char * ), 



*AddGenSpecLatConned ( char # r char * I, 
*DelGenSpecLatConnect( char #, char # ), 
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#AddWholePartConned ( char #, char *, 

int Constraint ::NOT APPLY, 
int Constraint ::N0T~APPLY, 
int Constraint ::N0T_APPLY, 
int Const raint::NOT_APPLY ), 
sDelWholePartConnedt char *, char * ); 

Message #AddInstanreConned( char #, char #, 

int Constraint: :W3T_APPLY, 
int Constraint: :NDT APPLY, 
int Constraint: :NGT~APPLY, 
int Constraint: :N0T~APPLY ), 
#DelInstanceConned( char *, char * ), 

*AddMessageConned ( char *, char #, Connect ionCategory ), 
*DelMessageConnect< char #, char *, ConnedionCategory ); 

Message #AddAttribute( char *objname, char #attrna»e), 

*DelAttribute( char *objname, char sattrname ), 
#AddAttrTypeAndSe»an( char *objnairie, char *attrname, 
char *type, char »senian ), 

*AddService( char *objname, char #serna»e ), 

#DelService( char *objnane, char *sername ), 
#AddServTypeAndSeBan( char sobjnarse, char aservnaise, 
char #type, char *seinan); 

Location ##RetGsHierarchyPtsList( char *, char * ), 
**RetGsLatticePtsList( char #, char # ), 
saRetWpConPtsListt char #, char * ), 

**RetInstConPtsList( char *, char * ), 
**RetMsgConPtsList( char *, char #, Connect ionCategory ); 

tfojedld RetOidC char #objnaae ); 
void RetObjLoct char *, Location * ), 

GetClassNamet Object Id, char * ); 

Message *GetClassList ( char ## ), 

*GetWholePartConInfo( char #, char *, int *, int *, 

int #, int * ), 

#6etInstanceConInfo( char *, char #, int #, int *, 

int *, int * ), 

#GetAttributeList( char *, char *# ), 

#6etServiceList( char #, char *# ); 

void SetAttrTypeAndSeaant char *, char *, char #, char * ), 
SetServTypeAndSemant char *, char *, char *, char * ); 

I; 


tendif 



/#*****#*###*#####**** Class implementation of ******************* 
#***##*#####*#******#* Drawing Sheet ****#s»**x*j«****s*/ 

♦ifndef _DR6SH_H 
♦define _DRGSH_H 

♦include "ooa.h" 

♦include <stdio.h> 


const DRGLEN 

= 100, 

// default length of the Drawing Sheet. 

DRSWID 

= 30; 

II default width of the Drawing Sheet. 

class DrawingSheet { 


private: 



unsigned 

Len, 



Hid; 


char 

#Fname; 


FILE 

#SchemaFile; /# strores the virtual drawing sheet #/ 


void OpenSchemaFilet char * ); 
public: 

DrawingSheett char * ="ooa.sch" r 

unsigned =DRBLEN, unsigned =DRGWID ); 

“DrawingSheett); 

unsigned Length 0; 
unsigned Widtht); 

/* thhe following three methods are used to read from FILE stream */ 
void Seek (long offset, int base); 

void Readtchar #buf, int count); 

long Telit); 

void Opent char * ), 

Closet void ), 

Expand ( int, int ), 

HriteHStringt char *, Location * ), 

UriteVStringt char *, Location # ); 

1 ? 


♦endif 



/a*###*##*###*#####*#### Class implementation of #*#*####$###»#***# 
#####*##*#«#*S*#*J«**S* CldSsiObject iHHHHHHBHW#####***/ 


#ifndef _CLSN0BJ H 
Idefine _CLSN08J~H 

♦include "connects.h" 

♦include “attrserv.h" 

♦include “ooa.h” 

♦include 'message. h* 

const MAX 6S CONNECTIONS = 15, MAX WP CONNECTIONS = 15, 
MAX_MSS_CONf£CT I ONS = 15, MAX jl©r_CDNNECTIONS = 15, 
MAX_ATTRIBUTES = 25, MAX_SERVICES = 25; 


enum DeleteType 1 

N0T_DESTR0Y = 0, DESTROY = 1 

I; 


class ClassNffiiject f 
private: 

Qbjectld Oid; 
char *ClsName; 
ClassType Type; 


BenSpecConnection 

MessageConnection 
WiDlePartConnection 
Inst anceConnect ion 


*6sHierarchy[HAX SS CONNECTIONS], 
sGslatticeCMAX GS COWECTIONS3; 
*MsgCons[MAX_MS6 CONNECTIONS!; 
aUpConstHAXjiPJENNECTIONSl; 
#InstCons[MAX JNST CONNECTIONS]? 


Attribute *AttributesfMAX ATTRIBUTES!; 

Service *Services[MAX_SERVICES!; 

Location *Loc; 


static unsigned NextOid; 


// the following methods are called by 
// Schema Manager while loading schema 
GenSpecConnection *RetGsHierarchyPtr( Object Id, Object Id ), 
#Ret6sLatticePtr( Objectld, Objectld )? 
WiolePartConnection sRetUpConPtrt Objectld, Objectld ); 
InstanceConnection #RetInstConPtr( Objectld, Objectld ); 
MessageConnection #RetMsgConPtr( Objectld, Objectld, 

Connect ionCategory ); 


public: 

ClassNQbjectt char * =NULL, ClassType =CLASS, 
Location * =NULL ); 
TlassNObjectO; 
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friend class SchemaManager; 
friend class Model ingManager; 

static unsigned GenOidO { return NextOid++; } 

static void SetOid ( unsigned seed ) { NextOid = seed; 1 

Message atAddGenSpecHyConnect ( GenSpecConnection * ), 
atDelGenSpecHyConnectl SenSpecConnection at, 

DeleteType =D£STR0Y J r 

*AddGenSpecLatConnect ( GenSpecConnection * ), 
atDelGenSpecLatConnect ( GenSpecConnection at, 

DeleteType =DESTR0Y ) r 

*AddWrolePart Connect ( WholePartConnection at ), 

*DelHholePartConnect( WholePartConnection at, 

DeleteType =DESTR0Y ), 

atAddlnstanceConnectt Inst anceConnect ion at ), 
atDellnstanceConnectt Inst anceConnect ion at, 

DeleteType =DESTR0Y ), 

atAddMessageConnectt MessageConnect ion at ), 
atDelMessageConnectt MessageConnect ion at, 

DeleteType =DESTR0Y ), 

atAddAttributel Attribute at ), 
atDel At tribute! char at ), 
atAddAttrTypeAndSemant char at, char at, char at ), 

atAddServicet Service at ), 
atDelServicet char at ), 

atAddServTypeAndSemant char at, char at, char at); 

Location atatfletGsHierarchyPtsLisU Object Id, Objectld ), 
atatRetGsLatticePtsListl Objectld, Objectld ), 
atatRetWpConPtsListt Objectld, Objectld ), 
atatRetlnstConPtsListt Objectld, Objectld ), 
atatRetMsgConPtsList ( ttajectld, Objectld, 

Connect ionCategory ); 

Objectld RetOidl void ) { return Oid; 1 
char at RetClsNamet char atbuf ) 

C return strcpyt buf, ClsNane ); 1 
ClassType RetClsTypet void ) i return Type; } 

Location atRetLod void ) { return Loc; 1 


lend if 



/a########***###*###**## Class iaplexentation of #*#*»#**»#***#** 
«»**##***###*****#**** Structures and Connections ********%*******/ 


♦ifndef _C0NNECTS H 
♦define _C0NNECTSJ 

♦include "ooa.h" 

class Connection ( 
protected: 

Qbjectld FroxOid, ToOid; 
public: 

Location *ConPtsList[ HAX_C0NN_PTS ]; // public member field 

Connection! (fcjectld, Ob jed Id ): 

"Connection!); 

Location #*RetPtsList! void ); 

Objectld RetFromOid ( void ); 

[fcjectld RetToOid! void ); 

1 ; 


inline Location #*Connection::RetPtsList!) 
{ 

return ConPtsList; 

1 


♦endif 


♦ifndef 

CCONNECT H 

♦define 

_CCOWECT_H 

♦ifndef 

_CONSTRAINT 

♦define 

_CONSTRAINT 

class 

Constraint { 

int 

Vail, Val2; 

enum 

{ N0T_APPLY = 


public: 

Constraint! int vl =NQT_APPLY, int v2 =N0T_APPLY ) { 
Vail = vl; Val2 = v2; 

1 

void SetVall! int v J C Vail = v? 1 
void SetValJ! int v ) f Val2 = v; 1 

int RetValSO i return Vail} 1 
int RetVal2() ( return Val2; 1 



tendif 


class ConstrainedConnedion : public Connection { 
protected: 

Constraint FromConst, ToConst; 
public: 

ConstrainedConnedion! Objedld, Objedld, 

int fvall Constraint: :N0T APPLY, 
int fval2 Constraint ::N0T APPLY, 
int tvall Constraint ::N0T~APPLY, 
int tval2 Constraint: :N0T_APPLY ); 

int RetFromConst Valid; 
int RetFro®ConstVal20? 
int RetToConstVallO; 
int RetToConstVal20; 

1 ; 

tendif 

tifndef JIPCONH 
idefine _WPC0N_H 

class WholePartConnection : public ConstrainedConnection 1 
// no member fileds 

public: 

ItiolePartConnectiont Object Id, Objedld, 

int fvall Constraint::tiBT_APPLY, 
int fval2 Constraint ::N0T~APPLY, 
int tvall Constraint: :N0T_APPLY, 
int tval2 Constraint: :N0T_APPLY ); 
i; 

tendif 

tifndef _6SC0N_H 
tdefine _6SC0N_H 

class BenSpecConnection : public Connection { 

// no member fields 

public: 

BenSpecConnectiont Objedld, Objectld ); 

tendif 

tifndef J1S8C0N H 
tdefine _HS6C0N_H 

class MessageConnedion : public Connection { 

Connect ionCategory Catg; 



public: 

MessageConnection! Objectld, Objectld, ConnectionCategory ); 
Connect ionCategory RetCatgO; 


#endif 

fifndef _INSTCONT_H 

Idefine _INSTC0N_H 

class InstanceConnection : public ConstrainedConnection C 
// no aeaber fileds 

public: 

InstanceConnection! Objectld, djectld, 

int fvall Constraint: :N0T APPLY, 
int fva!2 Constraint: :N0f APPLY, 
int tvall Constraint: :N0T_APPLY, 
int tval2 Constraint: :t®T APPLY ); 

1 ; 


#endif 



/a#####*####***## Class implementations for a######*#*#**##*#*** 
##*###»*######*# Attribute and Service mm^*##***#**#*#/ 


iifndef ATTRSERV H 

#define _ATTRSERV_H 

♦include <string.h> 

class Attribute { 
char #Name, 

#Type, /# attribute type #/ 
*Se»an; /* attribue semantics */ 


public: 

Attribute! char # =NULL ); 

“Attributed; 

void SetTypeAndSemantics! char * =NULL, char # =NULL); 

void SetTypeAndSemantics! char *, char * ); 

char #RetAttrNase( char *buf ) { return strcpyt buf, Name ); 1 


J; 

class Service C 
char *Name, 

aflype r /* service type */ 

*Seman; /* service semantics #/ 

public: 

Service! char # =#J_L ); 

“Serviced; 

void SetTypeAndSemantics! char # =NULL, char * =NULL); 

void SetTypeAndSemantics! char s, char * ); 

char #RetServName( char »buf ) { return strcpyt buf, Name ); 1 


1 ; 


tendif 



/##*##*############*##* Class implementation of **#*#*###*#####** 
a**#*##**#*#####*##*### Info Windows ******* *********** / 

♦ifndef INF0WIN_H 

♦define _INF0WIN_H 

const N0_NUM = 0, 

NUM = 1? 

♦include “window.h" 

class InfoDisplayWindow : public Window { 
public: 

InfoDisplayWindow! char * ); 

void Displaylnfo! char ** r int =NW1 ); 


class ClassDisplayWindow : private InfoDisplayWindow f 
public: 

ClassDisplayWindow! void ); 
void DisplayClasses! char ** )? 


class WholePartDisplayWindow : private InfoDisplayWindow { 
public: 

WholePartDisplayWindow! void ); 

void DisplayltiolePartConnect! char ** ); 


class InstanceConDisplayWindow : private InfoDisplayWindow f 
public: 

' InstanceConDisplayWindow! void ); 
void DisplaylnstanceConnect! char ** J; 


class AttributeDisplayWindow : private InfoDisplayWindow { 
public: 

AttributeDisplayWindow! char * ); 
void DisplayAttributes! char #* ); 


class ServiceDisplayWindow : private InfoDisplayWindow C 
public: 

ServiceDisplayWindow! char # ); 
void DisplayServicest char ** ); 


♦end if 



/a####**####**##****##*# Class implementation of ^#*##*#**#**##*#*##» 
a#***#*##*##**#*#******# User Interface Window *#*#^#m#**###*#**/ 


iifndef _INTFWIN H 
♦define _INTFWIN_H 

iinclude "vindov.h" 

class Box f 
public: 

char sheading; 
char sContent; 
int Left, Top, Right, Btro,* 
int TextAttr; 

Box( char *, int, int, int, int, int, int ); 
“BoxO; 

KEY Getlnputt void ); 

char sGetContentlntot char * ); 

>; 


class InterfaceWindow : public Window f 
private: 

Box »#InpBoxes; 
int BCount; 

void GetBoxInputsO; 

KEY GetOneBoxInputt Box * 1, 

IktOKFroaUserO; 

protected: 

void DisplayBoxest void ); 
public: 

InterfaceWindow! char *, int, int, int, int, int, int, int ); 
“InterfaceWindovO; 

void AddBoxToInter facet Box #, int ); 
int GetlnputCountO? 
char sGetlnputlntot char *, int ); 
void GetlnputsO; 

1 ; 



inline void InterfaceWindow::AddBoxToInterface( 

Box #box_ptr, int index ) 


1 


InpBoxest index ] = box_ptr; 

} 

inline int InterfaceWindow::GetInputCount() 
{ 


return BCount; 

} 

inline char #InterfaceWindow::6etInputInto( char #buf, int which ) 
{ 

return InpBoxesI which 3->GetContentInto( buf ); 

1 

inline void InterfaceWindou::Get Inputs!) 

{ 

DisplayBoxesO; 

SetBoxInputsO; 


#endif 
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/*********************** Class implementation of ******************* 
************************ Dialog Windows 

♦ifndef INTFWINS H 

♦define _INTFWINS~H 

♦include "intfwin.h" 

class ScheisaNaneWindov : public InterfaceWindow f 
public: 

SchemaNameWindow 0 ; 
if 


class ClassAddWindow : public InterfaceWindow { 
public: 

ClassAddWindowO; 

n 

class ClassNameWindow : public InterfaceWindow { 
public: 

ClassNameWindowt char * ); 

}; 


class ClassDelWindow : public ClassNameWindow { 
public: 

ClassDelWindowO; 

}? 


class ClassRelocateWindow : public ClassNaaeWindow { 
public: 

ClassRelocateWindowO; 

I; 


class ClassRepaintWindow : public ClassNameWindow t 
public: 

ClassRepaintWindow! ); 

}; 

/************************************************************/ 

static class AttributeAddDelWindow : public InterfaceWindow f 
public: 

AttributeAddDelWindowt char * ); 

h 

class AttributeAddSenanWindow : public InterfaceWindow I 
public: 

AttributeAddSesanWindowO; 

}; 


class AttributeAddWindow : public AttributeAddDelWindow i 



public: 

AttributeAddWindowO; 

if 

class AttributeDelWindow : public AttributeAddDelWindov { 
public: 

AttributeDelWindawO; 

1? 


class AttrBrowseWindow : public CiassNaseWindow { 
public: 

AttrBrowseWindowO; 

1 ? 


static class ServiceAddDelWindow : public Inter faceWindow { 
public: 

ServiceAddDelWindowt char * ); 

1 ; 


class ServiceAddSemanWindow : public InterfaceWindow { 
public: 

Ser viceAddSenanWindow ( ) ; 

l; 


class ServiceAddWindow : public ServiceAddDelWindow I 
public: 

ServiceAddWindovO; 

If 


class ServiceDelWindow : public ServiceAddDelWindow I 
public: 

ServiceDelWindow! ); 

If 


class ServBrowseWindow : public ClassNasteWindow ( 
public: 

ServBrowseWindowO; 

If 


static class GenSpecAddDelWindow : public InterfaceWindow I 
public: 

GenSpecAddDel Window ( char # ); 

If 


class 6enSpecHyAddWindow : public GenSpecAddDelWindow { 
public: 

GenSpecHyAddWi ndow ( ) ; 

1 ; 


class SenSpecHyDelWindow : public BenSpecAddDelWindow { 



public: 

GenSpecHyDe 1 Hi ndow ( ) ; 
i? 


class GenSpecLatAddWindow : public GenSpecAddDelHindow { 
public: 

6enSpecLatAddHindowO; 

i; 

class 6enSpecLatDelHindow : public 6enSpecAddDelHindow { 
public: 

GenSpecLatDelWindowO; 

i; 


class Inst ConAddHi ndow : public InterfaceHindow f 
public: 

InstConAddWindowO; 

1 : 


class InstConSelectHindow : public InterfaceHindow { 
public: 

InstConSelectHindow! char s ); 

If 


class InstConDelHindow : public InstConSelectHindow 1 
public: 

InstConDelHindowO; 

l; 

class InstConBrowseHindow : public InstConSelectHindow { 
public: 

InstConBrowseHindow ! ) ; 
if 


static class MesgConAddDelUindow : public InterfaceHindow { 
public: 

HesgConAddDelHindow! char * ); 

l: 


class MesgConAddHindow : public HesgConAddDelHindow { 
public: 

MesgConAddHindow!); 

if 


class MesgConDelHindow : public MesgConAddDelHindow f 
public: 

MesgConDelHindow!); 

if 
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/»****#*****#***##**#**)(**#*****#*#**#**#*#*»*#*)«(*#)«(#****!«)»/ 

class WholePartAddWindow : public InterfaceWindow { 
public: 

WholePartAddWindovO; 

1 ; 


class WiolePartSeledHindow : public InterfaceWindov { 
public: 

WholePartSelectWindowt char » ); 

h 


class HholePartDelWindow : public WiolePartSelectWindow C 
public: 

HholePartDelHindowO; 

1? 


class kfriolePartBrovseWindow : public HholePartSelectWindow C 
public: 

IfcolePartBrowseWindov! ) ; 

i; 


class DrgShtExpandUindou : public InterfaceWindow f 
public: 

DrgShtExpandWindowl int, int ); 

l > 

■> r 


fendif 



/a**###################### Class implement ions of *##*###**#####**#* 
**#****#*#*###*###**### Henu Window, Help Window a##**####**#***# 
«######*#****####*#* Report Window, and Error Window a***##*####**#/ 

tifndef _HHEWIN H 
idefine _MHEWIN~H 

♦include “window, h” 

/*#*#*##**##*###**#»»* Henu Window m****#####*#*****##*#*#**/ 
class HenuWindow : public Window { 

struct text_info WindSetSave; // for saving previous window settings 
public: 

HenuWindowt void ); 
void DisplayHenut char * ); 

friend void HenuDisplayt char # ); II prototype of this is in COfWON.H 

); 

/##*#} »#**####*##*# Help Window & Report Window a##**#**#***#**/ 

class HessageWindow: public Window { 
public: 

HessageWindow ( char * ); 

l; 


class HelpWindow : public HessageWindow { 

struct text_info WindSetSave; // for saving previous 

// window settings 

public: 

HelpWindowt void ); 

void DisplayMessaget char * ); 

friend void HelpHessaget char * ); // prototype of 

this is in COHHON.H 


}; 


class ReportWindow : public HessageWindow { 

struct text_info WindSetSave; // for saving previous 



public: 

ReportWindowf void ); 

void DisplayMessageC char * ); 

friend void Repor t Message ( char * ); // prototype of 

// this is in COMMON.H 




/a####**##**#*#*##*##* Error Window ##***»**»*#********»***)«/ 


class ErrorWindow : public Window { 

struct text_info WindSetSave; // for saving previous 

// window settings 

public: 

ErrorWindowt void ); 

void DisplayMessage( char * ); 

friend void ErrorMessaget char * ); // prototype of 

// this is in COMMON.H 


l; 


lend if 



/####*######)«**#*####«###* Class implementation of a*##*#*#**#*#####* 
##*#*#**#*###*#*»***#** **#* Window ********#*m##**x/ 

lifndef _WIND0W_H 
#define _WIND0W_H 

•include "common. h" 

•include ’ooa.h’ 

♦include <conio.h> 

enum LineType { 

NO LINE = 0, 

SINGLE LINE = 1, 

DOUBLE LINE = 2 

I; 

class Window t 
protected: 

Location Cur; 

int Left, // xl coordinate of the screen chunk 

Top, // yl coordinate of the screen chunk 

Right, // x2 coordinate of the screen chunk 

Btm; // y2 coordinate of the screen chunk 

int TextAttr; // text attribute information 
char #Title; Ji title of the window 

char *WinDispSave; 

struct text_info WinlnfoSave; 

void GetTextlnfo! struct text_info # ), 

SetTextlnfot struct text_info * ); 


public; 

Windowtchar #, int r int,int,int, int,int); 
"Window!); 

virtual void OutLine! LineType ); 

int NoveCurLeft! unsigned ), 
HoveCurRight! unsigned ), 
NoveCurUp! unsigned ), 

HoveCurDown! unsigned ); 

void SetCurTo! unsigned, unsigned ), 
HoveCurTo! Location * ), 

ResetCur! void ); 



void SetFgcBgdint, int), 
SetFgcBgdvoid), 
SelTitlet char * ), 
Clear! void ); 


1 ; 


inline void Window: :SetFgcBgd) 
{ 

textattr! TextAttr ); 

} 


inline void Window: :Clear() 
{ 

drscrO; 

} 


#endif 



/a#*##***#*##**##*##*##* Class implementation of *#****«{****##*»***« 
m*#*#*##****#*##**##** Message ****»*####*#****#*#/ 

lifndef _MESSA6E H 
♦define _MESSASE_H 

♦include <string.h> 

class Message { 
public: 

enu* Result f 

Failure = l r Success = 2 
} Status; 

char *Msg; 

Message! Result, char # =NULl ); 

“Messaged; 

J; 


♦endif 



Appendi x-C 


This Schema Store file for the our case study problem 
of Students Registration system. 


6 6 

C 0 Person 1 (28,2) 

2 

#0 14 (33,?) (33,11) (20,11) (20,14) # 

# 0 2 4 ( 38,9) (38,11) (56,11) (56,14) * 

0 

0 

0 

0 

3 Address Na®e Dept 
0 

] 

[ 1 Student 2 (11,15) 

2 

# 0 1 4 ( 33,9) (33,11) (20,11) (20,14) # 

# 1 3 4 (20,22) (20,24) (16,24) (16,28) # 

0 

1 

# 1 2 1 2 (28,16) (49,16) # 

0 

2 

# 1 2 1 2 0 4 2 (28, IB) (49,18) # 

# 1 4 0 10 1 -1 4 (28,20) (31,20) (31,25) (39,25) # 

3 Rolljta Programme Finjassistance 

1 Take guide 

) 

E 2 Instructor 2 (50,15) 

1 

# 0 2 4 (38,9) (38,11) (56,11) (56,14) # 

0 

1 

# 1 2 1 2 (28,16) (49,16) # 

0 

2 

# 1 2 1 2 0 4 2 (28,18) (49,18) # 

# 2 5 0 3 1 -1 4 (67,18) (84,18) (84,34) (80,34) # 

1 Initials 

2 Guide student Offer course 

3 

t 3 Regd student 2 (11,29) 

F 

# 1 3 4 (20,22) (20,24) (16,24) (16,28) # 

0 

2 

# 3 5 4 2 (28,34) (62,34) # 

# 3 4 1 4 (28,30) (32,30) (32,26) (39,26) # 

0 
0 

2 Regdjate acadjear 

3 Take courses Pay dues Drop course 

3 

C 4 Dues 2 (40,24) 

0 
0 
1 


88 



#3414 <28 r 30) (32,30) (32,26) (39,26) # 

0 

1 

# 1 4 0 10 1 -1 4 (28,20) (31,20) (31,25) (39,25) # 

2 Amount Due Jo 

1 ftecv jsayoent 

[ 5 Course 2 (63,33) 

0 

0 

1 

# 3 5 4 2 (28,34) (62,34) # 

0 

1 

# 2 5 0 3 1 -1 4 (67,18) (84,18) (84,34) (80,34) # 

3 Course _no Title Units 

1 Validate ^course 



Append i x-D 


This is Schema Information file for our case 
problem of Students Registration system. 


6 

[ Person 
3 

# Address String / Address of the person / # 

# Name String / Name of the person / I 

# Dept String / the department to which he belongs / # 

0 

] 

[ Student 
3 

# Roll_No Long_integer / Roll no of the student / # 

# Programme String / his programme of study I # 

# Fin_assistance String / Financial assistance he is getting / # 

1 

# Takejjuide / void Take_guide( Instructor ) / / takes an instructor as his guide / # 

I 

I Instructor 
1 

1 Initials String / Instructor's name initials / # 

2 

# Buide_student / void Buide_student( Student ) / / guides a student / # 

# Offer course / void Offer course! Course J I ! offer a course for this semester / # 

1 

[ Regd student 

2 

I Regd_date String / date on which he registered for this semester / # 

# acadjear String / the academic year of registration date / # 

3 

< Take jrourses / void Take_courses( Course * ) II takes the courses for this semester / # 
I Pay_dues / void Pay_dues( Amount ) / I clear the dues of the last semester / I 

# Drop course / void Drop_course( Instructor, Course ) / / drops a registered course / # 

] 

[ Dues 


study 
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2 

# Amount Amount / due amount of a student / # 

# Due_to String / due to whom / # 

1 

# Recv_payment / void Recv_payment( Student, Amount ) / / receive the payment from the student / # 
] 

[ Course 
3 

# Course_.no String / code no of the course / # 

# Title String / title of the course / # 

i Units String / the units for the course / # 

1 

# Validate jzourse / void Validate_course( Course ) / / check the validity of the course / # 

3 



Appendi x-E 


This 


is Schema Templates file for our case study probl 


of Students Registration System. 


/#*****# Thp class templates for the schema are as follows *###*#*/ 

class Person { 
private: 

String Address; 

String Name; 

String Dept? 


class Student : public Person { 
private: 

Instructor #instanceJoJnstructor? 

Dues #instanceJojDues; 

Instructor smessagejojnstructor; 

Longjnteger Rolljto; 

String Programme; 

String Fin_assi5tance; 

void Take_guide( Instructor ) ? 


class Instructor : public Person £ 
private: 

Student *instanceJo_Student; 

Course *instance_to_Course; 

Student smessagejojitudent; 

String Initials? 

void Guide jstudentt Student ) ? 
void Offer course! Course 1 ? 
h 


class Regdjtudent : public Student { 
private: 

Course wessageJoJSourse; 

Dues amessagejojlues; 

String Regdjiate; 

String acadjear? 

void Takejcourses! Course * ) ; 

void Payjues! Amount ) ? 

void Dropjrourset Instructor, Course ) ; 
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class Dues { 
private: 

Student #instance_to_Student; 

Regd_st udent stmessage _t o_Regd_st udent ; 

Amount Amount; 

String Due_to; 

void Recv_payment( Student, Amount ) ; 

}; 


class Course I 
private: 

Instructor *instance_to_Instructor; 

Regd_st udent *message_to_Regd_st udent; 

String Course _no; 

String Title; 

String Units; 

void Validate course! Course ) ; 

h 


/#****##*####*» This is the end of the file a###*#*##**##*/ 



Appendi x-F 


This is Analysis Document file for our case study probl 
of Students Registration System. 


/#***#****# The Document for the schema follows *****####/ 


CLASS NAME :: Person 

USAGE :: Only as class 

ATTRIBUTES :: 

NAME :: Address 
TYPE :: String 
SEMANTICS :: 

Address of the person 
NAME i! Name 
TYPE :: String 
SEMANTICS :: 

Name of the person 
NAME :: Dept 
TYPE :: String 
SEMANTICS :: 

the departient to which he belongs 


PUBLIC INTERFACE :s 

Services are absent 

DERIVED FROM CLASSES :i 

No other class 

COMPOSED OF CLASSES :: 

No other classes 


ASSOCIATED WITH :: 

No other class 

COMMUNICATES WITH 

No other class 


END OF THE CLASS Person 

a ASS NAME :: Student 

USAGE :: Both as class and object 

ATTRIBUTES :: 

NAME :: Roll Jo 
TYPE Longjnteger 
SEMANTICS :f 

Roll no of the student 
NAME ss Programme 
TYPE :: String 
SEMANTICS :: 

his programme of study 
NAME :: Finjassistance 
TYPE :: String 
SEMANTICS :: 



Financial assistance he is getting 


PUBLIC INTERFACE 

NAME :: Takejuide 
PROTOTYPE :: 

void Take jguide! Instructor ) 
SEMANTICS :: 

takes an instructor as his guide 

DERIVED FROM CLASSES :: 

Person 

COMPOSED OF CLASSES 

No other classes 

ASSOCIATED WITH ;; 

Instructor 

Dues 

COMMUNICATES WITH :: 

Instructor 

END OF THE CLASS Student 
CLASS NAME :: Instructor 

USAGE :: Both as class and object 

ATTRIBUTES :: 

NAME :: Initials 
TYPE :: String 
SEMANTICS i: 

Instructor's naae initials 

PUBLIC INTERFACE 

NAME :: 6uide student 
PROTOTYPE :: 

void Guide student! Student ) 
SEMANTICS :: 

guides a student 
NAME :: Offer course 
PROTOTYPE :: 

void Offer_course( Course ) 
SEMANTICS :: 

offer a course for this senes ter 

DERIVED FROM CLASSES :: 

Person 

COMPOSED OF CUSSES :: 

No other classes 

ASSOCIATED WITH :: 

Student 

Course 

COMMUNICATES WITH :: 

Student 

END OF THE CLASS Instructor 
CLASS NAME Regd^student 

USAGE :: Both as class and object 


ATTRIBUTES 
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NAME :: Regd date 
TYPE i: String 
SEMANTICS :: 

date on which he registered for this semester 
NAME :: acad year 
TYPE :: String 
SEMANTICS :: 

the academic year of registration date 


PUBLIC INTERFACE :: 

NAME Take courses 
PROTOTYPE :f 

void Take_courses( Course * ) 
SEMANTICS :: 

takes the courses for this semester 
NAME :: Pay dues 
PROTOTYPE ;7 

void Payjtuest Amount ) 

SEMANTICS :: 

dear the dues of the last semester 
NAME :: Drop course 
PROTOTYPE 

void Drop course ( Instructor, Course ) 
SEMANTICS :: 

drops a registered course 

DERIVED FROM CLASSES :: 

Student 

COMPOSED OF CLASSES :: 

No other classes 

ASSOCIATED WITH :: 

No other class 

COMMUNICATES WITH :: 

Course 

Dues 

END OF THE CLASS Regdjstudent 
CLASS NAME :: Dues 

USABE :: Both as class and object 

ATTRIBUTES :: 

NAME :: Amount 
TYPE i: Amount 
SEMANTICS :: 

due amount of a student 
NAME :: Due Jo 
TYPE :: String 
SEMANTICS :: 

due to whom 


PUBLIC INTERFACE :: 

NAME :: Repayment 
PROTOTYPE :: 

void Recv j»ay»ent ( Student, Amount ) 
SEMANTICS :: 

receive the payment from the student 

DERIVED FROM CLASSES :: 

No other class 


COMPOSED OF CLASSES :: 



No other classes 


97 


ASSOCIATED WITH :: 

Student 

COMMUNICATES WITH :: 

Regd_student 


END OF THE CLASS Dues 
CLASS NAME :: Course 

USAGE :: Both as class and object 

ATTRIBUTES :: 

NAME :: Course no 
TYPE :: String" 

SEMANTICS :: 

code no of the course 
NAME :: Title 
TYPE :: String 
SEMANTICS 

title of the course 
NAME :: Units 
TYPE :: String 
SEMANTICS :: 

the units for the course 

PUBLIC INTERFACE :: 

NAME Validate course 
PROTOTYPE :: 

void Validate course! Course > 
SEMANTICS :: 

check the validity of the course 

DERIVED FROM CLASSES :: 

No other class 

COMPOSED OF CLASSES :: 

No other classes 

ASSOCIATED WITH :: 

Instructor 

COMMUNICATES WITH :: 

Regd_student 

END OF THE' CLASS Course 


/*#*******##**» This is the end of the Docusent 



